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Abstract 


The Transformation portion of the HST Proposal Entry Processor System converts an 
astronomer-oriented description of a scientific observing program into a detailed description 
of the parameters needed for planning and scheduling. The Transformation system is one 
of a very few rulebased experts systems that has ever entered an operational phase. The 
day to day operation of the system and its rulebase are no longer the responsibility of the 
original developer. As a result, software engineering properties of the rulebased approach 
become more important. In this paper, we discuss maintenance issues associated with the 
coupling of rules within a rulebased system and offer a method for partitioning a rulebase 
so that the amount of knowledge needed to modify the rulebase is minimized. This method 
is also used to develop a measure of the coupling strength of the rulebase. 
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Space Administration 


1 Introduction 


The Hubble Space Telescope (HST) is an orbiting optical observatory to be launched by the 
Space Shuttle in late 1988. Using a rulebased expert system written in OPS5, the Transfor- 
mation system converts an astronomer-oriented description of a scientific observing program 
into a detailed description of the parameters needed by the planning and scheduling portion 
of the HST Science Operations Ground Support System. 3 Transformation has been in an 
operational phase since December 1985. During its early stages of the operational phase, 
the primary designer and implementer of the rulebased portion of the Transformation Sys- 
tem remained responsible for development and maintenance of the rulebase. Eight months 
later, the system was turned over to a member of the software group who had limited 
prior exposure to the project. The Transformation system is one of a very small number of 
rulebased expert systems that has entered an operational phase. Rulebased systems have 
traditionally been developed as research projects, and have been maintained by their orig- 
inal implementers. As expert system techniques and technolgy mature, a trend towards 
developing rulebased systems for practical applications will occur. These systems will be 
developed with the expectation that they will grow and evolve throughout the life of the 
project. With this evolution, the notion of a software life cycle becomes relevant and the 
software life cycle that rulebase systems undergo does not correspond to that of conven- 
tional software systems. 4 Unlike software problems that are solved by a more algorithmic 
approach, AI programs tend to implement problems which have not been completely speci- 
fied. As a result, expert systems raise some interesting software engineering considerations. 
In this paper, we discuss some of the maintenance issues associated with the coupling of 
rules for a rulebased system. We present a method for partitioning a rulebase in such a 
way that the knowledge required to make a modification to the rulebase is minimized. The 
method is also used to derive a metric that can be used as a measure of coupling strength. 


2 Background 


In OPS5, like many expert system languages, knowledge is encoded as a set of rules or 
productions with the following format: 

IF antecedents THEN consequents 

Facts from a global database, usually termed working memory, are matched with the an- 
tecedents (also referred to as left hand side or LHS). The matched rule/facts pairs (in- 
stantiations) are put into a conflict set. A conflict resolution strategy is applied to the 
set to determine the instantiation to be fired. During the firing process , the consequent 
prescribed by the rule corresponding to the instantiation is established. In general, this 
process creates new facts, and the inference cycle proceeds to the match step. This process 
continues until the conflict set is empty or the process is halted explicitly by the program- 
mer. This paradigm encourages the opportunistic behavior of rules and when the situation 
is right (e.g. when the antecedents match the facts), the rules are instantiated and fired. 

3 Transformation is described in detail in (7| 

4 See 5 for more information 
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This phenomenon distinguishes rulebase systems from an algorithmic approach to software 
problems. In other words, the order of application of the program’s functional pieces (in 
this case rules), is not built into the program, and will not be determined until runtime. 

On another level, such inferencing systems may seem to be common coupled. In common 
coupling, functional modules are linked through a global data structure. In OPS5 any rule 
may potentially read or write any part of working memory since rules share the entire 
working memory data area. However, working memory is partitioned into elements of 
data classes (analogous to traditional data structures), and rules refer to working memory 
elements by class name, and attribute (field) name. Therefore, coupling in rulebased systems 
more closely resembles stamp coupling. Stamp coupling is similar to common coupling 
except that the global data items are shared more selectively between components that use 
them. 5 

The partitioning of groups of rules according to a goal strategy is presently one of the more 
viable method of controlling inferencing in OPS5 (compared to, for example running several 
smaller ruebased programs in sequence). There is no way for the developer to “program'’ 
the conflict resolution strategy, she may only choose between MEA and LEX. 6 Meta rules 
are not presently possible due to the strict partitioning of rule memory, working memory, 
and the conflict set. 7 

The Transformation rulebase is a goal oriented rulebase which consists of seven goals, some 
of which contain sub goals and task lists, but all control is imposed at a very high level. The 
rulebase is “partitioned” into goal sets which reside in files; that is, rules pertaining to a 
specific goal or subgoal are found in a single file. When writing rules, the natural tendency 
is to group rules according to their functionality. For instance, a knowledge engineer might 
group in a file all rules that merge exposures. From the maintainers standpoint, this method 
has its disadvantages as well as advantages. The most obvious advantage is that if a new 
rule to merge exposures needs to be added, there are several examples for a maintainer to 
follow. In addition, if a problem arises in how exposures are merged, the problem area may 
be localized, and hence easier to debug. The disadvantage lies in what occurs downstream 
from this problem. For instance, if a new rule is added to merge exposures, what else might 
that change affect? This is a formidable problem for a maintenance programmer who is not 
well versed in the structure inherent in the rulebase. 

Other AI developers 8 have suggested an automated approach to partitioning a rule set 
based on a measure of “relatedness” . Rules would be grouped according to the facts that 
they share - where a fact is some data representation that if changed in one rule would affect 
another rule in some way. Since there are several ways in which two rules could reference the 
same fact, the facts would be weighted, and the measure of “relatedness” would be based on 
these facts. The rulebase would then be partitioned into groups according to how strongly 
rules were related. Although these arguments and the related tools have merit, there are 
still some issues that need to be addressed. For instance, choosing a measure of relatedness 
is still a rather arbitrary process, although a more sophisticated clustering algorithm to 
partition the rulebase might be helpful. In addition, within a partitioned rulebase, there 

s See [4i and [2j for a complete discussion of common and stamp coupling 

* Refer to jl] for an explanation of MEA and LEX 

7 See [6] for a discussion of meta rules 

$ See 13] for details 
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may be subtle interactions between rules within a set of grouped rules or between the groups 
themselves. Moreover, the grouping procedures do not guarantee a small number of groups. 
What is needed then, is a method for maintenance programmers to understand the coupling 
of rules in general. 


3 A Model for Partitioning a Rulebase 


We first take a look at the possible ways in which rules may be coupled. We know that 
rules are related to one another through the facts that they share. In OPS5 there are 
essentially three different ways of altering facts in working memory; through a make, modify 
or remove. A make creates a new working memory element. A remove deletes a working 
memory element from the database. Conceptually, a modify is a combination of a make 
and a remove. It deletes a working memory element, and replaces it with the appropriate 
new working memory element. 

Below is an example of two rule which are coupled by a make action. (All of the following 
examples are actual rules from the Transformation rulebase. For the purposes of under- 
standing how rules are coupled, it is not necessary to comprehend the semantic content of 
the rule.) The first rule, Find-parallel-wzth-metgeable-exposures uses the make command 
to create a working memory element with class name mergeable- exposures* Since the spec 1 
ified attributes of this working memory element “match” a subset of the antecedent of 
rule Remove-mergeable-exposures-if-same-mode-diff-aperture, we consider these rules to be 
related. 


(p f ind-parallel-with-mergeable- exposures 


merge- exposures 
active 

f ind- po t ent i a 1 - expo sure - merges ) 


(goal 

* has -name 
“has-status 
"task-list 

(exposure- link 

"has- exposure -number 
"is-linked-to 
"has -link- type 

(mergeable- level 
"symbol 
"value 


<parallel-exposure> 
<pr imary - expo sure > 
parallel-with ) 

parallel-with 

<parallel-with-level>) 


(make mergeable- expo sures 

"f ir st- exposure -number 

"second-exposure-nuaber 

"is-unaergeable 

"is -mergeable- level 

"merge-type 

"has-unique- label 


<primary-exposure> 
<par al lei- expo sure> 
false 

<paral lei- with- lsvel> 
parallel-with 
(genatom) ) ) 
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(p Ramova-margaftbla-axpoaures-if - 


(goal 

‘"haa-nama 

"haa-atatua 

~taek-liat 


aama-moda-dif f -apartura 


marga-axpoauraa 

activa 

find-pot ant ial-axpoaura-nargaa) 


(axpoaura-apacif ication 

~ia-intarnal-targat-typa 
~haa-axpoauxa-numbar 
~f irat-apartura-uaad 

(margaabla-laval 

‘aymbol 

~valua 

{<aargaabla-axpoaura-link> 

(margaabla-axpoeuraa 

~f irat-axpoaura-numbar 
~ia -margaabla-laval 
"aacond-axpo aura -number 

(axpoaura-apacif ication 
~haa-oxpoaura-mimbar 
~ia-intarnal-targat-type 
irat-apartura-uaad 


<> I 

<f irat-axpoaura> 
<apartura> 


parallal-with 
<parallal-vith-laval> ) 


<f irat-axpoaura> 
<parallal-with-laval> 
<aacond-axpoaura> ) > 

<aacond-axpoaura> 

<> I 

<> <apartura> 


(modify <margaabla-axpoaura-link> 
*1 unmargad-axpoauraa) ) 


When discussing relatedness, it is important to keep in mind that this is a static analysis 
°. * P J° em * Because rulebas ed systems are data driven, rules will interact differently 
Wit I erent sets of data. A static approach to the problem is simply, what portion of the 
rulebase might possibly be affected by a particular rule change, given any set of data. 

Figure 1 gives a pictorial representation of the relationship between these two rules. It 
shows that if Find-parallel-with-mergeable-ezposureswere modified, there is a possibility that 
Femove-mergeable-exposures-if-same-mode-diff-aperture might be affected by the change. 



Figure 1.0 Coupling Rules through a make action 
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Next we look at two rules that are coupled by a remove action. The rule, Remove-mergeable- 
exposures-if- fir st-is-an- acquisition removes a working memory element that may have been 
created by Find-parallel- with-mergeable-exposures: 


(p find parallal-with- margaabla-axpoauraa 


marga-axpoauraa 

activa 

f ind-potantial-axpoaura-margaa) 


(goal 

~haa-nama 
~haa-atatua 
~taak-liat 

(axpoaura-link 

~haa-axpoaura-numbar 

~ia-linkad-to 

~haa-link-typa 

(margaabla-laval 

“aymbol 

“valua 


<parallal-axpoaura> 
<primary-axpoaura> 
parallal-with ) 


parallal-with 

<parallal-with-laval>) 


(maka margaabla-axpoauraa 

*f irat-axpoaura-numbar 

‘aacond-axpoaura-numbar 

"ia-unaargaabla 

~ia-margaabla-laval 

"marga-typa 

~haa-uniqua-labal 


<priaary-axpoaura> 
<para 11a 1-axpo aura > 
falaa 

<parallal-with-laval> 
parallal-with 
(ganatom) ) ) 


(p Ramova-margaable-expoauraa-if -f irat-ia-an-acquiaition) 


(goal 

"haa-nama marga-axpoauraa 

M haa-atatua activa 

liat f ind-pot ant ia 1-axpo aura -margaa) 

{<aargaabla-axpoaura-liiik> 

(margaabla-axpoauraa 

*f irat-axpoaura-numbar <f irat-axpoaura> ) > 

(axpoaura-link 

"haa-axpoaura-numbar <f irat-axpoaura> 

"haa-link-typa <<0NB0ARD-ACQ INT-ACQ > ) 


(ramova <margaabla-axpoaura-link>) ) 

We will represent the relationship of two rules coupled by a remove as is shown in figure 
2.0. Note that we picture the relationship slightly different for a remove coupling than 
we did for a make coupling. In the case of a remove , the arrow is pointing in the 
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opposite direction to show that in order for Find-parallel-with-mergeable-exposures to be 
affected by a modification of the rule Remove- mergeable-exposures-if-first-is-an-acquisition, 
Find-parallel-with-mergeable-exposures must already have been instantiated based on this 
working memory element. 



Figure 2.0 Coupling Rules through a remove action 


In order to demonstrate the coupling created by a modify, it is necessary to use three rules. 
The first rule Remove-fos-hrs-merge-if-only-second-mode-is-rapid uses the modify action 
to change the class name of mergeable-exposures to unmerged-exposures. Since the specified 
attributes of the working memory element with class name unmerged-exposures u matches r 
the antecedent of the rule link-alignments-with-unmerged-exposures, these rules are said to 
be coupled. On the other hand, when Remove-fos-hrs-merge-if-only-mode-is-rapid uses the 
modify action to change the class name of a working memory element it is in affect removing 
the working memory element mergeable- exposures. So, based on the same principle as the 
remove example, we consider these two rules also to be coupled. 


(p Find-same-orientation-mergeable-exposures 


(goal 

"ha a -name 

"hae-status 

"task-list 


msrgs- exposures 

active 

f ind-potential-exposure-nerges ) 


(expo sure -link 

"has -expo sure -number 

"is-linked-to 

"haa-link-type 


< 1 inked-expoaure> 
<main-exposure> 
SAME-ORIENT ) 


(exposure- specification 
"has -expo sure -number 
"uses -SI -configuration 


<main-exposure> 
<SI-conf iguration> ) 


( exposure- specif icat ion 
"has -expo sure -number 


<linked-exposure> 
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‘uses-SI-conf iguration 

(mergeable- level 
‘symbol 
‘value 


<SI-conf iguration> ) 

same-orientation 

<same-orientation-level>) 


(make mergeable -exposures 

*£ irst- expo aura -number 

‘second-exposure-number 

‘is-unmergeable 

‘is-mergeable- level 

‘merge-type 

‘has -unique- label 


<main-expoaure> 

< linked- expo sure > 
trua 

<same-orientation-level> 
same -orient at ion 
(ganatoa) ) ) 


(p Remove -f os-hra-merge-if -only- second-mode- is-rapid 
(goal 

‘has -name marge -expo aura a 

‘haa-statua activa 

‘task-list f md-potantial-axpoaura-margaa ) 


{<mergeable-exposure-link> 
(mergeable -exposures 

* f ir at - expo aura - number 
‘second- exposure -number 
‘merge-type 

‘ia-unmergeable 

(expo sure- spec if ication 
‘has -expo aura -number 
‘uses -SI- configuration 
‘uses- SI -operating-mode 

(exposure- specif ication 
‘ha a -exposure -number 
‘uses- SI -operating-mode 


<f irst-expoaure> 

< second- exposure> 
<<aequence-no-gap consecutive 
same- orient at ion>> 
true) > 


<f irat-expoaure> 

<< foa/bl foa/rd hra >> 
<> rapid ) 

< second- expo aura> 
rapid ) 


(modify <aargaable-expoaure-link> 

"1 unaerged- expo auras )) 


(p 1 ink- alignment a -with-unmerged- expo sure a 
(goal 

‘has-name merge- alignment a 
‘haa-atatua active 

‘teak- li at find-potential -alignment -merges) 
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(unmergsd-sxposurss 

"f irst-sxposurs-numbsr <f irst-sxposurs -number > 

"f irst-copy-numbsr <first-copy> 

* second- sxposurs- number < a econd- expo sure- number > 
"sscond-copy-numbsr <sscond~copy> ) 

(assignment -rscord 

"has -Pspsi- sxpo sure -number <f irst-exposure-number> 

"is -assignment -record-copy-number <i irst-copy> 

"has -alignment -order <f irst -alignment -order> 

) 


(assignment -record 

"has-Pepsi -expo sure -number < second- expo sure -number> 
"is-assignment -record-copy-number <second-copy> 
"has-alignment-order { <second-alignment-order> <> 

<f irst -alignment- order > > 

) 


(make mergeable-alignments 

"has-f irst -alignment -order <f irst-alignment-order> 
"has- second- alignment -order < second- alignment- order > 
"has-unique-label (genatom) ) ) 



Figure 3.0 Coupling Rules through a modify action 


4 A More Formal Way to Express Coupling 
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What we have seen so far is that if two rules are coupled by our definition, the rhs of one 
rule feeds the lhs of another rule. But what is actually meant by one rule feeding another? 
Let's introduce a notation to make the notion precise. 

We can think of a rule as consisting of three parts: its name, its associated conditions, and 
its actions. A rule j is denoted by Rj . 
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R A( C }.1 - C;,n) — (flj, 1 -Q ; ,m)) 


The first condition of the Ihs of ft is called c ]A , the second c h2 and so on. Similarly the 
first action will be a Jtl and so forth. 

We say ft feeds R , if the pattern corresponding to some action of ft , say a, z matches 
some condition clause of rule ft, say c,,„. This is expressed in a predicate calculus as : 

3 X 3 J/ (pm ( fp a j,x c t,y)) 

where / p is a function that given some rule action returns the pattern to which the rule 
action corresponds, and p m is a predicate that takes two patterns and returns true if they 
match and false otherwise. 

As examples of the notation suppose ft is the rule find-parallel-witk-mergable-ezposures 
and ft is the rule Remove-mergable-exposures-if-first-i$-an~acquisition. Then: 

Up = 

(merge able- exposures 
'first -proposal -id 
'first-version 
'first -exposure-number 
'second -proposal -id 
'second- version 
'second-exposure-number 
'is-unmergeable 
'is-mergeable- level 
'merge-type 
'has -unique -label 

and 
C|, 2 is 

(mergeable- exposure s 
'first -proposal -id 
'f irst-version 
'first -exposure -number 

an< 3 ( Pm Up ay, i) c ti2 ) is true. 

The general operation of the predicate p m on the simple type matches should now be 
presented. If the element class of two patterns differs, then the predicate returns false. 
Otherwise, an attribute by attribute match is attempted. If an attribute is paired with a 
variable in one or both patterns, then the patterns match on that attribute. If they both 
are paired with the same constant, then again they match. If the attribute is not mentioned 
in the condition pattern, then it matches the action pattern for the attribute. Note that 
the p m predicate returns true if all corresponding pairs of attributes match. 


<parallel -proposal- id> 

<parallel-version> 

<primary- exposure > 

<parallel -proposal -id> 

<parallel-version> 

<parallel-exposure> 

false 

<paral lei -with- level > 

parallel-with 

(genatom) 


<proposal-id> 

<version> 

<f irst-exposure> ) 
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5 Using the Network 


Clearly if every rule is coupled with every other rule in the system then the system is 
completely coupled. The maximum number of arcs is then n 2 , where n is the number of 
rules in the rulebase. The ratio of actual arcs in the network to n 2 is a measure of the 
degree to which the rulebase is coupled. If the ratio is unity then any rule could interfere 
with any other. The lower the ratio the more local is the effect of a typical rule in the 
rulebase and the higher the degree of stamp coupling in the system. 

To find the group of rules whose behavior may be directly affected by the addition of a new 
rule we need only regard the network of rules. Figure 4.0 represents a part of the network 
for some rulebase. The dotted arcs in the figure represent the new coupling that will occur 
if rule new-rcmove is added to the rulebase. Suppose for the sake of simplicity that both 
R1 and R6 contain a single make action on their rh*. The solid coupling lines flowing from 
R1 represent the match that occurs between the newly created wme from the make action 
of Rl and the conditional elements on the Ihs of R2 and R3, (This is also true for the 
solid lines between R6 and R3,R4, and R5). The dotted line from Rl to new-rcmove shows 
that the make-pattern which creates a working memory element will match some set of 
conditional elements on the LHS of ncw-rcmove. 



Figure 4.0 Grouping Rules 


Now, note that it is only possible to remove something from the right hand side of a rule, 
if the pattern is matched on the left hand side of that same rule. Therefore, the pattern 
of the element removed in ntw-rtmovt will match some condition in R2 and R3. If neu/- 
rule fires, and instantiations corresponding to rules R2 and R3 are in the conflict set, the 
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instantiations will be removed. Thus, the behavior of rules R2 and R3 is altered by the 
addition of new-remove. If R2 and R3 are not fully matched, they will exist in the Rete 
network. In this case, the new-remove will push these rules farther away from the conflict 
set. Note also that the behavior of R1 is not affected by the addition of new-remove . 

We can make a similar argument for rules R4 and R5 based on the coupling between R6 
and new-remove. Simply put, the group of rules affected by the addition of new-remove will 
be those rules with the same parent as new rule (i.e. the siblings of new- remove). 

We therefore see that the group of rules that the new rule could possibly affect directly 
is { i?2 » #3? #5 } * Naturally the instantiations actually affected by the firing of a rule 

depends on the data on which a system is operating and the conflict set resolution strategy. 

The case for adding a new make rule is similar. The group of rules whose behavior might be 
affected directly is the set of all immediate successors to the new rule. A new modify, since 
it is functionally the same as a make and remove, will affect the union of the two groups 
directly. 

Although we have not yet implemented the tool for construction and transversal of the 
network, its implementation in Lisp should be fairly straightforward. The formal presenta- 
tion is written mostly in terms of predicates and functions. A dialect of Lisp that supports 
object-oriented programming could be used to represent nodes by making each node in the 
net an instance of a “rule class”. Methods could be attached to these classes that would 
retrieve a rule’s predecessors, successors, etc. Having devised this general framework for 
determining coupling between rules, our work is now directed toward implementing this 
tool and exercising it on the Transformation system. 


6 Conclusions 


The Transformation system is one of a small group of rulebased systems that has entered 
into an operational phase. Because the original developer is no longer involved with the 
day to day operations of the system, the software engineering attributes of the system have 
become more important. This paper has focused on the nature of rule coupling in the 
system and has presented a method for understanding the coupling properties of the OPS5 
rulebase. We have constructed a general network depicting how rules are coupled within 
a rulebase, and this network is the basis for deriving a measure of the degree of common 
coupling for the rules within the rulebase. Furthermore, we have shown how a tool which 
operates on the principles of this network will allow a maintainer to modify a rulebase with 
a clearer understanding of how the modification will impact the existing rulebase. 
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